The representation of three-dimensional (3D) graphics on a two-dimensional (2D) display involves numerous steps that are performed one after the other in pipelined fashion. With reference to FIG. 1A, there is shown a typical 3D graphics drawing pipeline including various processing modules.
At the outset, an artist creates a set of 3D models, which are represented using a series of primitives represented by interconnected points known as vertices. The primitives and their vertices are stored in display lists 106 where each vertex contains several pieces of information about itself, such as its position, color, texture, reflectivity, etc. Once a software application determines what objects will be present in the 3D scene being drawn and how they are arranged, the appropriate display list 106 is sent to the geometry processing module 102.
The geometry processing module 102 performs calculations that modify and, in some cases, create new data for vertices. These operations are executed by graphics hardware typically embodied as a special-purpose graphics processing unit (GPU) which is in communication with a host central processing unit (CPU). Alternatively, if these operations are not supported by the graphics hardware, they can be executed in the host CPU, but this almost always results in greatly reduced performance. Once the vertex data has been processed by the geometry processing module 102, the processed primitives with their vertices are then passed on to a rendering stage 104A for conversion into pixels.
Thus, the objective of the rendering stage 104A is to convert three-dimensional primitives (processed by the geometry processing module 102) into two-dimensional picture element (pixel) data. This is accomplished by passing the vertices of each primitive through a setup module 112, which links the vertices together to form triangles. The triangle information is then provided to a pixel shader module 116A, whose role it is to “fill” each pixel with the appropriate color. Those skilled in the art will appreciate that the color of each pixel has to be chosen carefully in order to give the 2D image the appearance of depth and texture.
The pixel shader module 116A runs a pixel shader program which is executed on individual pixels as they pass through the rendering stage 104A of the 3D graphics pipeline. The pixel shader module 116A computes a final shade for each pixel by processing the triangles that influence that pixel. Furthermore, in order to apply the correct texture information (e.g., reflectivity, transparency, etc.) to each pixel, the pixel shader module 116A interacts with a texture processing module 130A, which accesses a texture memory 128.
It should be noted that the color information provided to the pixel shader module 116A can be represented in a variety of formats. In some cases, the color information of a particular triangle could be provided as a color space vector of three coefficients in a red-green-blue (RGB) color space. In other cases, the color space vector may consist of three coefficients in a luminance-chrominance (YCbCr, or YUV) color space. Since some functions of the texture processing module 130A are better suited for execution in one color space rather than another, it may be necessary to convert a given color space vector into a different color space prior to texture processing.
To this end, the texture processing module 130A will typically interact with a color space conversion (CSC) module 110 prior to causing the execution of the pixel shader code by the pixel shader module 116A. The operations performed by the color space conversion module 110 conventionally involve the use of specialized logic gates for performing the mathematical expressions relating to color space conversion.
After completion of processing by the pixel shader module 116A, the processed pixels are provided to a blending module 118 at the end of the rendering stage 104A. Once the blending module 118 has completed its processing, the final colors of each pixel in the rendered image are written to a block of memory called the frame buffer 124. From this point, the image can either be sent back through the pipeline again for further processing (e.g., by the blending module 118), or sent to a display processing module 140A for further processing.
The display processing module 140A has the ability to read the frame buffer 124 and to provide the data contained therein to a display 142 for the purposes of displaying the data (e.g., on a screen). Depending on the data format accepted by the display type (e.g., RGB or YUV) and depending on the color space in which the data is stored in the frame buffer 124, the display processing module 140A may be required to access an additional color space conversion module 122. As with the color space conversion module 110, the color space conversion module 122 typically involves the use of specialized logic gates for performing the mathematical expressions relating to color space conversion.
It may also be desirable to change certain key parameters of a video data stream, such as color saturation, hue, brightness and/or to provide definition control (contrast). These functions are collectively referred to as video processing amplifier controls, or “procamp” controls, in analogy to the well known video processing amplifiers that operate on analog video signals. To this end, the texture processing module 130A may communicate with a procamp module 144 in order to perform procamp controls prior to causing the execution of the pixel shader code by the pixel shader module 116A, while the display processing module 140A may communicate with a procamp module 146 prior to displaying the pixels on the display 142. The procamp modules 144, 146 usually involve the use of specialized logic circuits for performing the mathematical expressions relating to the procamp controls.
As is known to those of ordinary skill in the art, the specialized logic circuits used in performing color space conversion and procamp controls functionality are typically implemented as ASICs (application-specific integrated circuits), PLAs (programmable logic arrays) or FPGAs (field-programmable gate arrays) adapted to execute millions of arithmetic operations (sums and products) per second. Consequently, these dedicated hardware elements occupy a relatively large semiconductor area, which consumes chip real estate that would otherwise be available to the GPU.
It should thus be apparent from the foregoing that the processing power of a GPU, which is responsible for performing numerous steps in the 3D graphics pipeline, is eroded by performing color space processing using specialized logic circuits. Accordingly, it would be desirable to provide the functionality of the color space processing modules 110, 122 and the procamp modules 144, 146 in a GPU without having recourse to the use of additional co-processing hardware.